[Draft] Manual edits in generated code to compiling against v0.4.0 gen output
#1959
Conversation
There was a problem hiding this comment.
Wrong directory for your crate, and you shouldn't modify generated code. @jhendrixMSFT looks like we need to run rustfmt on the emitted code. I thought you already were, though? It's been well formatted to date.
| @@ -14,6 +14,7 @@ members = [ | |||
| "eng/test/mock_transport", | |||
| "sdk/storage", | |||
| "sdk/storage/azure_storage_blob", | |||
| "sdk/storage/storage_blob", | |||
There was a problem hiding this comment.
This is not the right naming convention. You're azure_storage_blob.
There was a problem hiding this comment.
Hi Heath, that is correct. This is currently what is coming right out of the current routes and definitions in https://github.com/Azure/azure-rest-api-specs/blob/feature/blob-tsp/specification/storage/Microsoft.BlobStorage/tspconfig.yaml (aside from some stop-gap edits for NYI features).
As we are on that topic though, is this what you are envisioning regarding the structure?
Current example for where generated BlobBlobClient lives:
sdk/storage/storage_blob/src/generated/clients/blob_blob_client.rs
Desired destination:
sdk/storage/azure_storage_blob/src/generated/clients/blob_blob_client.rs
storage_blob would then be a module containing the generated client and models, and is defined and used in the azure_storage_blob crate? If so, I can pass this information along to Catalina and Joel that we are moving towards that directory structure- as presently this is what the results of the current latest typespec and emitter (v0.4.0) combination outputs: #1958
As for the hand-edits to generated code, that was for illustrating what the desired changes to generated code should look like, and is being tracked here: https://github.com/Azure/typespec-rust/issues/183
There was a problem hiding this comment.
storage_blob doesn't exist in that scenario. You'd have a azure_storage_blobs (plural; same naming convention as every other language) crate where the clients live in the root. Again, like most other languages. Implementations should be idiomatic, yes, but naming should be idiomatically consistent (i.e. the same, ignoring casing differences). That means for "packages" (nupkgs, wheels, jars, crates, etc.) as well as namespaces/modules.
|
We run |
@jhendrixMSFT I guess I was correlating the two. That's fine if the emitter itself doesn't run |
|
You'll need a script of some sort (this is how we do it in the emitter repo). |
As title states. Mostly for illustrative purposes.